Otherwise, if the VM is unexpectedly rebooted, then `importctl --user pull-tar`
may fail as the file may already exist.
```
[  123.351751] TEST-13-NSPAWN.sh[3946]: + run0 -u testuser importctl --user pull-tar file:///var/tmp/image-tar/kurps.tar.gz nurps --verify=checksum -m
[  123.541603] TEST-13-NSPAWN.sh[4311]: Enqueued transfer job 3. Press C-c to continue download in background.
[  123.552456] TEST-13-NSPAWN.sh[4311]: Pulling 'file:///var/tmp/image-tar/kurps.tar.gz', saving as 'nurps'.
[  123.552788] TEST-13-NSPAWN.sh[4311]: Operating on image directory '/home/testuser/.local/state/machines'.
[  123.819942] TEST-13-NSPAWN.sh[4311]: Got 1% of file:///var/tmp/image-tar/kurps.tar.gz.
[  124.156557] TEST-13-NSPAWN.sh[4311]: * shutting down connection #0
[  124.156896] TEST-13-NSPAWN.sh[4311]: * Could not open file /var/tmp/image-tar/kurps.tar.gz.sha256
[  124.157223] TEST-13-NSPAWN.sh[4311]: * closing connection #-1
[  124.159198] TEST-13-NSPAWN.sh[4311]: * Could not open file /var/tmp/image-tar/kurps.nspawn
[  124.159493] TEST-13-NSPAWN.sh[4311]: * closing connection #-1
[  124.159818] TEST-13-NSPAWN.sh[4311]: Acquired 68.5M.
[  124.160395] TEST-13-NSPAWN.sh[4311]: Download of file:///var/tmp/image-tar/kurps.tar.gz complete.
[  124.160664] TEST-13-NSPAWN.sh[4311]: Transfer failed: Could not read a file:// file
[  124.160923] TEST-13-NSPAWN.sh[4311]: Settings file could not be retrieved, proceeding without.
[  124.404733] TEST-13-NSPAWN.sh[4311]: * shutting down connection #1
[  124.405162] TEST-13-NSPAWN.sh[4311]: Acquired 79B.
[  124.406170] TEST-13-NSPAWN.sh[4311]: Download of file:///var/tmp/image-tar/SHA256SUMS complete.
[  124.406734] TEST-13-NSPAWN.sh[4311]: SHA256 checksum of file:///var/tmp/image-tar/kurps.tar.gz is valid.
[  124.455446] TEST-13-NSPAWN.sh[4311]: Failed to rename to final image name to /home/testuser/.local/state/machines/.tar-file:\x2f\x2f\x2fvar\x2ftmp\x2fimage-tar\x2fkurps\x2etar\x2egz: File exists
[  124.457251] TEST-13-NSPAWN.sh[4311]: Exiting.
```
Workaround for issue systemd#38240.

Fix a typo which causes a segfault when processing a user record
with matchHostname when it's an array instead of a simple string:

$ echo '{"userName":"crashhostarray","perMachine":[{"matchHostname":["host1","host2"],"locked":false}]}' | userdbctl -F -
Segmentation fault         (core dumped)

$ coredumpctl info
...
       Message: Process 1172301 (userdbctl) of user 1000 dumped core.

                Module libz.so.1 from rpm zlib-ng-2.3.3-1.fc43.x86_64
                Module libcrypto.so.3 from rpm openssl-3.5.4-2.fc43.x86_64
                Stack trace of thread 1172301:
                #0  0x00007fded7b3a656 __strcmp_evex (libc.so.6 + 0x159656)
                #1  0x00007fded7e95397 per_machine_hostname_match (libsystemd-shared-260.so + 0x295397)
                systemd#2  0x00007fded7e955b5 per_machine_match (libsystemd-shared-260.so + 0x2955b5)
                systemd#3  0x00007fded7e957c6 dispatch_per_machine (libsystemd-shared-260.so + 0x2957c6)
                systemd#4  0x00007fded7e96c97 user_record_load (libsystemd-shared-260.so + 0x296c97)
                systemd#5  0x000000000040572d display_user (/home/fsumsal/repos/@systemd/systemd/build/userdbctl + 0x572d)
                systemd#6  0x00007fded7ea9727 dispatch_verb (libsystemd-shared-260.so + 0x2a9727)
                systemd#7  0x000000000041077c run (/home/fsumsal/repos/@systemd/systemd/build/userdbctl + 0x1077c)
                systemd#8  0x00000000004107ce main (/home/fsumsal/repos/@systemd/systemd/build/userdbctl + 0x107ce)
                systemd#9  0x00007fded79e45b5 __libc_start_call_main (libc.so.6 + 0x35b5)
                systemd#10 0x00007fded79e4668 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x3668)
                systemd#11 0x00000000004038d5 _start (/home/fsumsal/repos/@systemd/systemd/build/userdbctl + 0x38d5)
                ELF object binary architecture: AMD x86-64

The fido2_hmac_salt/fido2_hmac_credential/recovery_key fields kept
leaking memory as the array itself wasn't deallocated after deallocating
each of its elements data:

$ build-san/userdbctl -F fuzz-corpus-userdb/auth-fido2.json
...
=================================================================
==1292840==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 112 byte(s) in 1 object(s) allocated from:
    #0 0x7f56f00e5e4b in realloc.part.0 (/lib64/libasan.so.8+0xe5e4b) (BuildId: 25975f766867e9e604dc5a71a8befeaed3301942)
    #1 0x7f56ed869e42 in greedy_realloc ../src/basic/alloc-util.c:65
    systemd#2 0x7f56ed7ff5e9 in dispatch_fido2_hmac_salt ../src/shared/user-record.c:836
    systemd#3 0x7f56edd73cbc in sd_json_dispatch_full ../src/libsystemd/sd-json/sd-json.c:5204
    systemd#4 0x7f56edd745fc in sd_json_dispatch ../src/libsystemd/sd-json/sd-json.c:5276
    systemd#5 0x7f56ed80100b in dispatch_privileged ../src/shared/user-record.c:998
    systemd#6 0x7f56edd73cbc in sd_json_dispatch_full ../src/libsystemd/sd-json/sd-json.c:5204
    systemd#7 0x7f56edd745fc in sd_json_dispatch ../src/libsystemd/sd-json/sd-json.c:5276
    systemd#8 0x7f56ed80622c in user_record_load ../src/shared/user-record.c:1697
    systemd#9 0x000000408c15 in display_user ../src/userdb/userdbctl.c:447
    systemd#10 0x7f56ed83cc9a in dispatch_verb ../src/shared/verbs.c:137
    systemd#11 0x00000041df2b in run ../src/userdb/userdbctl.c:1908
    systemd#12 0x00000041dfbe in main ../src/userdb/userdbctl.c:1911
    systemd#13 0x7f56ec8105b4 in __libc_start_call_main (/lib64/libc.so.6+0x35b4) (BuildId: 2b5beec0fd24fe9c9f43eddfdd5facf0b8a1b805)
    systemd#14 0x7f56ec810667 in __libc_start_main@@GLIBC_2.34 (/lib64/libc.so.6+0x3667) (BuildId: 2b5beec0fd24fe9c9f43eddfdd5facf0b8a1b805)
    systemd#15 0x000000404a44 in _start (/home/fsumsal/repos/@systemd/systemd/build-san/userdbctl+0x404a44) (BuildId: 19e8b7e7b7038d2cea20bc18a55bea2a9e4406d5)

Direct leak of 64 byte(s) in 1 object(s) allocated from:
    #0 0x7f56f00e5e4b in realloc.part.0 (/lib64/libasan.so.8+0xe5e4b) (BuildId: 25975f766867e9e604dc5a71a8befeaed3301942)
    #1 0x7f56ed869e42 in greedy_realloc ../src/basic/alloc-util.c:65
    systemd#2 0x7f56ed7fe779 in dispatch_fido2_hmac_credential_array ../src/shared/user-record.c:775
    systemd#3 0x7f56edd73cbc in sd_json_dispatch_full ../src/libsystemd/sd-json/sd-json.c:5204
    systemd#4 0x7f56edd745fc in sd_json_dispatch ../src/libsystemd/sd-json/sd-json.c:5276
    systemd#5 0x7f56ed80622c in user_record_load ../src/shared/user-record.c:1697
    systemd#6 0x000000408c15 in display_user ../src/userdb/userdbctl.c:447
    systemd#7 0x7f56ed83cc9a in dispatch_verb ../src/shared/verbs.c:137
    systemd#8 0x00000041df2b in run ../src/userdb/userdbctl.c:1908
    systemd#9 0x00000041dfbe in main ../src/userdb/userdbctl.c:1911
    systemd#10 0x7f56ec8105b4 in __libc_start_call_main (/lib64/libc.so.6+0x35b4) (BuildId: 2b5beec0fd24fe9c9f43eddfdd5facf0b8a1b805)
    systemd#11 0x7f56ec810667 in __libc_start_main@@GLIBC_2.34 (/lib64/libc.so.6+0x3667) (BuildId: 2b5beec0fd24fe9c9f43eddfdd5facf0b8a1b805)
    systemd#12 0x000000404a44 in _start (/home/fsumsal/repos/@systemd/systemd/build-san/userdbctl+0x404a44) (BuildId: 19e8b7e7b7038d2cea20bc18a55bea2a9e4406d5)

SUMMARY: AddressSanitizer: 176 byte(s) leaked in 2 allocation(s).

…d#40979)

Fix a typo which causes a segfault when processing a user record
with `matchHostname` when it's an array instead of a simple string:

```
$ echo '{"userName":"crashhostarray","perMachine":[{"matchHostname":["host1","host2"],"locked":false}]}' | userdbctl -F -
Segmentation fault         (core dumped)

$ coredumpctl info
...
       Message: Process 1172301 (userdbctl) of user 1000 dumped core.

                Module libz.so.1 from rpm zlib-ng-2.3.3-1.fc43.x86_64
                Module libcrypto.so.3 from rpm openssl-3.5.4-2.fc43.x86_64
                Stack trace of thread 1172301:
                #0  0x00007fded7b3a656 __strcmp_evex (libc.so.6 + 0x159656)
                #1  0x00007fded7e95397 per_machine_hostname_match (libsystemd-shared-260.so + 0x295397)
                systemd#2  0x00007fded7e955b5 per_machine_match (libsystemd-shared-260.so + 0x2955b5)
                systemd#3  0x00007fded7e957c6 dispatch_per_machine (libsystemd-shared-260.so + 0x2957c6)
                systemd#4  0x00007fded7e96c97 user_record_load (libsystemd-shared-260.so + 0x296c97)
                systemd#5  0x000000000040572d display_user (/home/fsumsal/repos/@systemd/systemd/build/userdbctl + 0x572d)
                systemd#6  0x00007fded7ea9727 dispatch_verb (libsystemd-shared-260.so + 0x2a9727)
                systemd#7  0x000000000041077c run (/home/fsumsal/repos/@systemd/systemd/build/userdbctl + 0x1077c)
                systemd#8  0x00000000004107ce main (/home/fsumsal/repos/@systemd/systemd/build/userdbctl + 0x107ce)
                systemd#9  0x00007fded79e45b5 __libc_start_call_main (libc.so.6 + 0x35b5)
                systemd#10 0x00007fded79e4668 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x3668)
                systemd#11 0x00000000004038d5 _start (/home/fsumsal/repos/@systemd/systemd/build/userdbctl + 0x38d5)
                ELF object binary architecture: AMD x86-64
```

There are only a few target dirs we place resources in when generating
on-the-fly initrd cpios. These dirs have very specific attributes.
Instead of repeating this everywhere, let's encapsulate them in a new
explicit structure, that we can reuse at various places.

This is preparation for placing extra resources of Type #1 entry also in
them without having to encode access modes at multiple places
redundantly.

On some architectures like m68k, alignof(void*) is 2, not sizeof(void*)
(which is 4). So the natural alignment of struct Option is 2 and
sizeof(Option) == 26.

However, each variable placed in the SYSTEMD_OPTIONS ELF section via
_OPTION() carries _alignptr_ (= __attribute__((aligned(sizeof(void*))))),
which forces each entry to start at a 4-byte boundary. The linker
therefore inserts 2 bytes of padding between adjacent entries, producing
an actual stride of 28 in the section.

option_parse() iterates over the section with pointer arithmetic
("opt++"), which advances by sizeof(Option) == 26 and lands inside the
padding. The fields read back as zero, and since commit cf88903
("tree-wide: get rid of most uses of ALIGN_PTR") added the ordering
assertion below, the resulting "0 < 0" trips it when running --help:

 Assertion 'opt->id < (opt + 1)->id' failed at src/shared/options.c:116, function option_parse(). Aborting.

 #0  0xc0a7b248 in ?? () from /usr/lib/m68k-linux-gnu/libc.so.6
 #1  0xc0a7b2ce in pthread_kill () from /usr/lib/m68k-linux-gnu/libc.so.6
 systemd#2  0xc0a2edc6 in raise () from /usr/lib/m68k-linux-gnu/libc.so.6
 systemd#3  0xc0a1c128 in abort () from /usr/lib/m68k-linux-gnu/libc.so.6
 systemd#4  0xc05c6f78 in option_parse (options=0x0, options_end=0x0, state=0xc09ca968) at ../src/shared/options.c:116

Fix this by applying _alignptr_ to the struct definition itself, so that
sizeof(Option) is padded up to a multiple of sizeof(void*) and matches
the actual on-disk stride. Add an assert_cc() so any future regression
is caught at compile time.

The same latent bug applies to Verb and TestFunc, which use the same
section-placement pattern. Their natural sizeof was already a multiple
of sizeof(void*) so no crash was observed, but apply the same fix
defensively.

Follow-up for cf88903

Co-developed-by: Claude Opus 4.7 <[email protected]>

sd_journal_get_data() can return a MESSAGE data object whose payload does
not start with "MESSAGE=", e.g. when the journal file is corrupted. Instead
of aborting the whole process, log and skip over such an entry like we do for
other bad/missing fields.

[   87.287390] post.sh[1619]: + journalctl -q -o short-monotonic --grep 'didn'\''t pass validation'
[   87.287844] post.sh[1620]: + grep -v test-varlink-idl
[   87.325676] post.sh[1619]: Assertion 'message = startswith(message, "MESSAGE=")' failed at src/journal/journalctl-show.c:261, function show(). Aborting.

 #0  0x00007fb47b49a29c n/a (libc.so.6 + 0x9a29c)
 #1  0x00007fb47b43e7d0 raise (libc.so.6 + 0x3e7d0)
 systemd#2  0x00007fb47b425681 abort (libc.so.6 + 0x25681)
 systemd#3  0x00007fb47b8a1ace log_assert_failed (libsystemd-shared-261~rc2.so + 0xa1ace)
 systemd#4  0x000055f8e1ef9ddb show (journalctl + 0xcddb)
 systemd#5  0x000055f8e1efa6ee action_show (journalctl + 0xd6ee)
 systemd#6  0x000055f8e1ef3c20 run (journalctl + 0x6c20)
 systemd#7  0x00007fb47b427741 n/a (libc.so.6 + 0x27741)
 systemd#8  0x00007fb47b427879 __libc_start_main (libc.so.6 + 0x27879)
 systemd#9  0x000055f8e1ef4915 _start (journalctl + 0x7915)

Co-developed-by: Claude Opus 4.8 <[email protected]>